在產品開發時，就會預設假想，所開發出來的產品會符合某一類型的使用者，而這一類型的使用者對於在使用產品上會有一些特定行為，而這些行為就會對應到一個功能或服務內容；而要如何預設這些行為的發生和目的，就可以夠過User Story來描述。

雖然User Story嚴格說來，是可以不包含產品規格(PRD)中的內容，但User Story是可以幫助所有開發相關人員，對於對應的開發功能作為一個討論的依據。

因為時候只是看功能的內容及規格，很容易會失焦，會對於功能技術性或深度專研討論下去，就可能開發一個技術很高深，但是實際產品應用上，是不用到那麼高強度的技術；而這時候有User Story就可以當作相關功能的討論技術時參考依據，讓相關人員可以定錨聚焦。

不過User story只是描述使用這需求，不做技術細節規格的展開，細節內容是在PRD中，在進行詳細的細節描述撰寫。

User Story撰寫的注意事項：
以使用者個角度去描述，需求內容，讓開發團隊可以了解使用者的需求及預期獲得價值
撰寫格式可參考下列內容

• As a ______, I want to ______, so that ______.
• 身為 ______，我想要 ______，所以可以讓我 ______。

範例參考：

• 身為一名使用者，我想要在登入頁看到品牌LOGO，所以可以確認我正在使用正確的應用程式。
• 身為一名平台管理者，我想要在首頁看到全部功能鍵，所以可以快速找到我需要的功能。

該格式是常見結構，但可以事宜的調整成，符合所屬組織的運作模式。
而結構內容至少須包含下列元素

1. 使用者：是什麼類型角色(Role)的使用者，會有相關需求，可以使用形容詞或情境描述，還強化開始該使用者特徵。
2. 需求：描述該使用者會需要什麼、做什麼行為的內容，來進行進而完成目標，可以使用動詞來表達該目標及行動。
3. 背後原因或價值：描述該需求行動的背後意義和目標，對使用者會有什麼重要的目的或洞見，盡可能描述出會達到的價值和成果會是什麼樣子。

較好閱讀的方式可採用表格方式進行，一個表格包含Side(Role)/User story/Function，讓相關人員可以透過一張表格可以了解需求規模

Take away

User story 是一個句話來描述使用者所期待的功能及服務內容，可以幫助他們完成是目標或價值；其實就是把需求內容轉譯成站在使用者的角度，去描述該目的的內容。

格式要包含使用者、需求、背後原因或價值，透過一個簡明的描述，讓開發團隊可以定錨開發。

每一個User Story都會需要對應到一個功能，讓需求與功能可以對照著看。